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Abstract 


Voice over IP (VoIP) typically uses the encapsulation 
voice/RTP/UDP/IP. When MPLS labels are added, this becomes 
voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is 
typically 48 bytes, while the voice payload is often no more than 30 
bytes, for example. Header compression can significantly reduce the 
overhead through various compression mechanisms, such as enhanced 
compressed RTP (ECRTP) and robust header compression (ROHC). We 
consider using MPLS to route compressed packets over an MPLS Label 
Switched Path (LSP) without compression/decompression cycles at each 
router. This approach can increase the bandwidth efficiency as well 
as processing scalability of the maximum number of simultaneous flows 


that use header compression at each router. In this document, we 
give a problem statement, goals and requirements, and an example 
scenario. 
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1. Introduction 


Voice over IP (VoIP) typically uses the encapsulation 
voice/RTP/UDP/IP. When MPLS labels [MPLS-ARCH] are added, this 
becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS Virtual Private 
Network (VPN) (e.g., [MPLS-VPN]), the packet header is at least 48 
bytes, while the voice payload is often no more than 30 bytes, for 
example. The interest in header compression (HC) is to exploit the 
possibility of significantly reducing the overhead through various 
compression mechanisms, such as with enhanced compressed RTP [ECRTP] 
or robust header compression [ROHC], and also to increase scalability 
of HC. We consider using MPLS to route compressed packets over an 
MPLS Label Switched Path (LSP) without compression/decompression 
cycles at each router. Such an HC over MPLS capability can increase 
bandwidth efficiency as well as the processing scalability of the 
maximum number of simultaneous flows that use HC at each router. 


To implement HC over MPLS, the ingress router/gateway would have to 
apply the HC algorithm to the IP packet, the compressed packet routed 
on an MPLS LSP using MPLS labels, and the compressed header would be 
decompressed at the egress router/gateway where the HC session 
terminates. Figure 1 illustrates an HC over MPLS session established 
on an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> 
R4/HD, where R1/HC is the ingress router where HC is performed, and 
R4/HD is the egress router where header decompression (HD) is done. 
HC of the RTP/UDP/IP header is performed at R1/HC, and the compressed 
packets are routed using MPLS labels from R1/HC to R2, to R3, and 
finally to R4/HD, without further decompression/recompression cycles. 
The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded 
to other routers, as needed. 
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ee Header Compression (HC) Performed 


| voice/compressed-header/MPLS-labels 


| voice/compressed-header/MPLS-labels 
V 


|R4/HD| Header Decompression (HD) Performed 


Figure 1. Example of Header Compression over MPLS 
over Routers R1-->R4 


In the example scenario, HC therefore takes place between R1 and R4, 
and the MPLS path transports voice/compressed-header/MPLS-labels 
instead of voice/RTP/UDP/IP/MPLS-labels, typically saving 30 octets 
or more per packet. The MPLS label stack and link-layer headers are 
not compressed. A signaling method is needed to set up a 
correspondence between the ingress and egress routers of the HC over 
MPLS session. 


In Section 2 we give a problem statement, in Section 3 we give goals 
and requirements, and in Section 5 we give an example scenario. 


2. Problem Statement 


As described in the introduction, HC over MPLS can significantly 
reduce the header overhead through HC mechanisms. The need for HC 
may be important on low-speed links where bandwidth is more scarce, 
but it could also be important on backbone facilities, especially 
where costs are high (e.g., some global cross-sections). VoIP 
typically will use voice compression mechanisms (e.g., G.729) on 
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low-speed and international routes, in order to conserve bandwidth. 
With HC, significantly more bandwidth could be saved. For example, 
carrying uncompressed headers for the entire voice load of a large 
domestic network with 300 million or more calls per day could consume 
on the order of about 20-40 gigabits per second on the backbone 
network for headers alone. This overhead could translate into 
considerable bandwidth capacity. 


The claim is often made that once fiber is in place, increasing the 
bandwidth capacity is inexpensive, nearly ’free’. This may be true 
in some cases; however, on some international cross-sections, 
especially, facility/transport costs are very high and saving 
bandwidth on such backbone links is very worthwhile. Decreasing the 
backbone bandwidth is needed in some areas of the world where 
bandwidth is very expensive. It is also important in almost all 
locations to decrease the bandwidth consumption on low-speed links. 
So although bandwidth is getting cheaper, the value of compression 


does not go away. It should be further noted that IPv6 will increase 
the size of headers, and therefore increase the importance of HC for 
RTP flows. 


Although hop-by-hop HC could be applied to decrease bandwidth 
requirements, that implies a processing requirement for compression- 
decompression cycles at every router hop, which does not scale well 
for large voice traffic loads. The maximum number of compressed RTP 
(cCRTP) flows is about 30-50 for a typical customer premise router, 
depending upon its uplink speed and processing power, while the need 
may exceed 300-500 for a high-end case. Therefore, HC over MPLS 
seems to be a viable alternative to get the compression benefits 
without introducing costly processing demands on the intermediate 
nodes. By using HC over MPLS, routers merely forward compressed 
packets without doing a decompression/recompression cycle, thereby 
increasing the maximum number of simultaneous compressed flows that 
routers can handle. 


Therefore, the proposal is to use existing HC techniques, together 
with MPLS labels, to make the transport of the RTP/UDP/IP headers 
more efficient over an MPLS network. However, at this time, there 
are no standards for HC over MPLS, and vendors have not implemented 
such techniques. 


2.1. Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEY]. 
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3- 


Goals and Requirements 
The goals of HC over MPLS are as follows: 


provide more efficient voice transport over MPLS networks, 

increase the scalability of HC to a large number of flows, 

c. not significantly increase packet delay, delay variation, or loss 
probability, and 

d. leverage existing work through use of standard protocols as much 

as possible. 


o 


Therefore the requirements for HC over MPLS are as follows: 


a. MUST use existing protocols (e.g., [ECRTP], [ROHC]) to compress 

RTP/UDP/IP headers, in order to provide for efficient transport, 

tolerance to packet loss, and resistance to loss of session 

context. 

b. MUST allow HC over an MPLS LSP, and thereby avoid hop-by-hop 

compression/decompression cycles (e.g., [HC-MPLS-PROTO]). 

c. MUST minimize incremental performance degradation due to increased 

delay, packet loss, and jitter. 

d. MUST use standard protocols to signal context identification and 
control information (e.g., [RSVP], [RSVP-TE], [LDP]). 

e. Packet reordering MUST NOT cause incorrectly decompressed packets 
to be forwarded from the decompressor. 


It is necessary that the HC method be able to handle out-of-sequence 
packets. MPLS [MPLS-ARCH] enables 4-byte labels to be appended to IP 
packets to allow switching from the ingress Label Switching Router 
(LSR) to the egress LSP on an LSP through an MPLS network. However, 
MPLS does not guarantee that packets will arrive in order at the 
egress LSR, since a number of things could cause packets to be 
delivered out of sequence. For example, a link failure could cause 
the LSP routing to change, due perhaps to an MPLS fast reroute taking 
place, or to the Interior Gateway Protocol (IGP) and Label 
Distribution Protocol (LDP) converging to another route, among other 


possible reasons. Other causes could include IGP reroutes due to 
‘loose hops’ in the LSP, or BGP route changes reflecting back into 
IGP reroutes. HC algorithms may be able to handle reordering 


magnitudes on the order of about 10 packets, which may make the time 
required for IGP reconvergence (typically on the order of seconds) 
untenable for the HC algorithm. On the other hand, MPLS fast reroute 
may be fast enough (on the order of 50 ms or less) for the HC 
algorithm to handle packet reordering. The issue of reordering needs 
to be further considered in the development of the HC over MPLS 
solution. 
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Resynchronization and performance also needs to be considered, since 
HC over MPLS can sometimes have multiple routers in the LSP. 
Tunneling an HC session over an MPLS LSP with multiple routers in the 
path will increase the round-trip delay and the chance of packet 
loss, and HC contexts may be invalidated due to packet loss. The HC 
error recovery mechanism can compound the problem when long round- 
trip delays are involved. 


4. Candidate Solution Methods and Needs 


[CRTP] performs best with very low packet error rates on all hops of 
the path. When the cRTP decompressor context state gets out of synch 
with the compressor, it will drop packets associated with the context 
until the two states are resynchronized. To resynchronize context 
state at the two ends, the decompressor transmits the CONTEXT_STATE 
packet to the compressor, and the compressor transmits a FULL_HEADER 
packet to the decompressor. 


[ECRTP] uses mechanisms that make cRIP more tolerant to packet loss, 
and ECRTP thereby helps to minimize the use of feedback-based error 
recovery (CONTEXT_STATE packets). ECRTP is therefore a candidate 
method to make HC over MPLS more tolerant of packet loss and to guard 
against frequent resynchronizations. ECRTP may need some 
implementation adaptations to address the reordering requirement in 
Section 3 (requirement e), since a default implementation will 
probably not meet the requirement. ECRTP protocol extensions may be 
required to identify FULL_HEADER, CONTEXT_STATE, and compressed 
packet types. [cRTP-ENCAP] specifies a separate link-layer packet 
type defined for HC. Using a separate link-layer packet type avoids 
the need to add extra bits to the compression header to identify the 
packet type. However, this approach does not extend well to MPLS 
encapsulation conventions [MPLS-ENCAP], in which a separate link- 
layer packet type translates into a separate LSP for each packet 
type. In order to extend ECRTP to HC over MPLS, each packet type 
defined in [ECRTP] would need to be identified in an appended packet 
type field in the ECRTP header. 


[ROHC] is also very tolerant of packet loss, and therefore is a 
candidate method to guard against frequent resynchronizations. ROHC 
also achieves a somewhat better level of compression as compared to 
ECRTP. ROHC may need some implementation adaptations to address the 
reordering requirement in Section 3 (requirement e), since a default 
implementation will probably not meet the requirement (see 
[ROHC-REORD]). ROHC already has the capability to identify the 
packet type in the compression header, so no further extension is 
needed to identify packet type. 
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Extensions to MPLS signaling may be needed to identify the LSP from 
HC to HD egress point, negotiate the HC algorithm used and protocol 
parameters, and negotiate the Session Context IDs (SCIDsS) space 
between the ingress and egress routers on the MPLS LSP. For example, 
new objects may need to be defined for [RSVP-TE] to signal the SCID 
spaces between the ingress and egress routers, and the HC algorithm 
used to determine the context; these HC packets then contain the SCID 
identified by using the RSVP-TE objects. It is also desirable to 
signal HC over MPLS tunnels with the Label Distribution Protocol 
[LDP], since many RFC 2547 VPN [MPLS-VPN] implementations use LDP as 
the underlying LSP signaling mechanism, and LDP is very scalable. 
However, extensions to LDP may be needed to signal SCIDs between 
ingress and egress routers on HC over MPLS LSPs. For example, 
‘targeted LDP sessions’ might be established for signaling SCIDs, or 
perhaps methods described in [LDP-PWE3] to signal pseudo-wires and 
multipoint-to-point LSPs might be extended to support signaling of 
SCIDs for HC over MPLS LSPs. The specific MPLS signaling protocol 
extensions to support these approved requirements need to be 
developed as a well-coordinated separate document in the appropriate 
IETF working groups. The IETF needs to support a coordinated process 
for the two solution documents, though they are in separate areas. 


5. Example Scenario 


As illustrated in Figure 2, many VoIP flows are originated from 
customer sites, which are served by routers Rl, R2, and R3, and 
terminated at several large customer call centers, which are served 
by R5, R6, and R7. R4 is a service-provider router, and all VoIP 
flows traverse R4. It is essential that the R4-R5, R4-R6, and R4-R7 
low-speed links all use HC to allow a maximum number of simultaneous 
VoIP flows. To allow processing at R4 to handle the volume of 
simultaneous VoIP flows, it is desired to use HC over MPLS for these 
flows. With HC over MPLS, R4 does not need to do HC/HD for the flows 
to the call centers, enabling more scalability of the number of 
simultaneous VoIP flows with HC at R4. 
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voice/C-HDR/MPLS-labels voice/C-HDR/MPLS-labels 
R1/HC---------------------- >| | ----------------------- > R5/HD 


voice/C-HDR/MPLS-labels voice/C-HDR/MPLS-labels 


R2/HC---------------------- >| R4 = |----------------------- > R6/HD 
voice/C-HDR/MPLS-labels | | voice/C-HDR/MPLS-labels 
R3/HC---------------------- >| | ----------------------- > R7/HD 
Note: HC = header compression 
C-HDR = compressed header 
HD = header decompression 
Figure 2. Example Scenario for Application of HC over MPLS 
6. Security Considerations 


The high processing load of HC makes HC a target for denial-of- 
service attacks. For example, an attacker could send a high- 
bandwidth data stream through a network, with the headers in the data 
stream marked appropriately to cause HC to be applied. This would 
use large amounts of processing resources on the routers performing 
compression and decompression, and these processing resources might 
then be unavailable for other important functions on the router. 
This threat is not a new threat for HC, but is addressed and 
mitigated by HC over MPLS. That is, by reducing the need for 
performing compression and decompression cycles, as proposed in this 
document, the risk of this type of denial-of-service attack is 


reduced. 
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